前言

如果已經很熟悉interface的觀眾，建議可以略過這幾篇。

如果還在卡關在interface面前的朋友，或許看了這幾篇，能夠稍微獲得一些靈感，能夠有點幫助的話那是筆者的榮幸。

筆者是學生時代，有物件導向語言的相關課程，為最先開始接觸到interface的契機，若從那時開始算起的話，可能經過了6~7年才懂得interface，並且會用、會設計。

卡了很久沒關係，也許某些事情就真的看悟性，筆者也不認為這部分自己很有天份XD，也不覺得有什麼好丟臉的。

也是golang的讓我真正認識interface，其他的語言也曾努力對interface下了許多功夫，結果總是好像隔了一層厚厚的隔閡，無法參透。

無法參透，就無法做出最合適，最好的設計，甚至別人寫的設計模式也會因此看不懂。

筆者自己深以為然，捅破interface的障礙，也就是開始看得懂golang source code到底在寫什麼的核心關鍵之一，就可以學習什麼樣的情境做什麼的設計，可以抄可以仿，寫出來的程式架構設計與以往相比，也會風格有所差異。

有壓力的環境

突破的動力源有兩者。

1. 為了研究golang底層是怎麼運作的：

產品發生的問題已經不是只管好自己寫的部分，就能解決或處理。API連線丟出去，DB連線丟出去，卻遇到奇奇怪怪的狀況，連線的過程就像個黑箱子，在箱子裡面出狀況，看不懂裡面的程式碼，無法了解發生了什麼問題。

2. 重構的任務太傻眼：

當程式碼大幅相似，只有小部分處理不一樣，卻類似複製貼上的方式出沒在整個專案的每處，專案有好幾萬的行數，整個受不了，並且極高度的耦合，任何修改難以輕舉妄動。

持續反思自己學習go的歷程

以最終產品來說，筆者認為不使用interface其實是沒關係的，程式寫得出來，東西也會跑，維護方面.....其實也沒說差到哪裡去。

筆者覺得自己有盡所能遵守coding style，嚴謹的處理每一塊程式，錯誤處理，驗證檢查什麼，每一塊程式業務處理也都抽得漂漂亮亮，也沒奇怪的全域變數亂用，但為什麼覺得我的程式有很嚴重的不協調感，最後感覺像茅坑的石頭又臭又硬？

這件事情我思考了兩個月，做了我所能做的一切努力，結果卻好像哪裡不太自然。如果問我說『這個專案需求，最後所撰寫出來的這些程式碼，是所能做得最好的嗎？』，我的答案一定是『不』。

況且，我還主持其他兩位夥伴一起完成這個專案的工作，我們到底怎麼了？我應該有某些責任，怎麼帶領大家設計出一個更合適的專案。

現在我有了答案，可以回答那時的困惑，答案就是我們『不是用golang的想法和理念』，去設計和撰寫golang的程式。

那什麼是所謂golang的想法？

一言難盡，但是系列文接下來的文章，筆者會儘量分享自己的理解。

有些會以像是導讀的方式，試圖講解程式碼寫法背後的考量和設計的用意。

我的方向是：放棄以往寫的方式，了解golang的特色，利用golang的專長，模仿golang的design pattern。

得到的結果，如下面描述，雖然有點抽象，前後感覺就是不一樣。

原本寫出來的程式，假設我將它切成5個大部分，每個大部分作的事情非常明確，若程式有狀況有問題，可以立馬鎖定在哪個部分，而每個大部分，細節又劃分了幾個部分，每個部分業務邏輯明確，可以各部分拆解或維修。

就像疊積木一樣，一塊一塊整齊往上疊，也可以抽換裡面的積木，但是，積木與積木的結合，像是用螺絲或者釘子固定住。

換積木前要先拔釘子，積木換上再重釘，雖然已經比起整坨爛泥好上不少，至少有積木可換，但是上下連接還是緊密相關，維護或調整雖然說可能不用到了解全局，但是還是得理解上下，還是得查看釘子在哪裡，拔出後才能調整，而且不免還是有些副作用。

每塊的業務邏輯有理有據，但接口十分硬性。

而換過想法的程式，感覺起來，這些積木是用卡榫結合在一起的，而非用破壞性的釘子或者螺絲使其結合，要抽換積木前，要了解的是結構，卡榫的特色就是一般應力的時候，物件彼此是緊密結合在一起，解開要往特定的方向或者施力方式。

好處是了解結構，看得懂才拆得出來XD，然後知道怎麼替換，某種程度上我就不會擔心有人亂改，因為會壞，而且破壞性能夠控制在某種程度。

只要看懂結構，修改也好改，比起之前的維護性，筆者認為若能夠培養一批人看懂golang的設計結構方式，後續維護和調整的工作就可以輕鬆，因為不用特地花大把力氣去仔細了解每個專案的業務邏輯，和熟悉資料結構怎麼借接，因為結構會告訴你這些事情，只要懂結構，就懂資料怎麼處理。